To troubleshoot client-to-virtual server connectivity

1. Make sure the IP address and dependent Network Name resources are online.
2. Use ipconfig /all to examine the TCP/IP configuration for all adapters. Make sure the IP address of the resource is registered to the correct adapter and that each adapter has a primary address. If the resource's IP address is not registered but the resource is online, take the resource offline and then bring it back online. If the address is still not registered with the correct adapter, consult the diagnostic cluster log.
3. If NetBIOS has been enabled for the IP address resource, verify that the network name is properly associated with its dependent IP address resource.

Use nbtstat to display the node's NetBIOS name registrations. For example, type the following at the Windows Server 2003 family command prompt:

nbtstat -n

The output from this command displays the IP addresses that are registered with NetBIOS. Cluster IP address resources are listed under the heading, \Device\NetBt_IFx, where x is a number. Under NetBIOS Local Name Table, you will find the NetBIOS names that are associated with the IP addresses. For each dependent network name, there are two entries: Name <20> and Name <00>, where Name is the virtual network name.

The following is an example of this output:

\Device\NetBt_If2:

Node ipAddress: [172.31.248.167] Scope Id: []

NetBIOS Local Name Table

Name	Type	Status
CLWCLUS	<20> Unique	Registered
CLWCLUS	<00> Unique	Registered

If the NetBIOS names are unregistered, or if there are registration conflicts, use nbtstat -rr to release the old NetBIOS names and renew their registrations. For example, type the following at the Windows Server 2003 family command prompt:

nbtstat -rr

4. Verify that DNS is available and functioning correctly.

Use the netdiag command line tool (available in the Microsoft Windows Server 2003 Resource Kit) to evaluate the registration of DNS. For example, type the following at the Windows Server 2003 family command prompt:

netdiag /test:DNS /d:xxx.xxx.xxx.xxx /debug

where xxx.xxx.xxx.xxx is the IP address of the virtual server.

If the output suggests that connectivity to the DNS server is suspect or DNS registration for the virtual name may have failed, check to see that the network connections on the virtual server are configured with the correct IP addresses of the DNS servers to be used for name resolution.

5. Try to ping the group's IP address from all clients and cluster nodes.

For example, on each client, and all cluster nodes, type the following at the Windows Server 2003 family command prompt:

ping xxx.xxx.xxx.xxx

where xxx.xxx.xxx.xxx is the IP address of the virtual server.

This tests for physical connectivity between the clients and cluster node, and between the cluster nodes.

6. Try to ping the virtual server network name from each client and cluster node.

For example, at the Windows Server 2003 family command prompt on each client and on all cluster nodes, type the following:

ping Netname

where Netname is the network name for the virtual server.

This test uses the appropriate name-resolution mechanism (DNS or WINS). If you can ping the IP address but ping returns unknown host when you ping the network name, then the client is unable to resolve the network name to an IP address. Check connectivity to the name server or servers by pinging their IP addresses (ipconfig all will list the addresses for each network adapter). If DNS is in use on the network but the name returned is not a fully qualified domain name (FQDN), (that is, just the NetBIOS name is returned), then connectivity to the DNS server is suspect or DNS registration for the virtual name may have failed.

7. If the virtual server has a File Share resource, try to connect to the resource using net use.

   For example, at the Windows Server 2003 family command prompt, type the following:

   net use * \\Virtualserver\Sharename

   where Virtualserver is the network name for the virtual server and Sharename is the share name for the File Share resource.

   If you are unable to connect to the resource, you may not have the appropriate permissions set for the resource. For more information, see "Set permissions on a shared resource" in Related Topics.

8. If clients are unable reconnect to the virtual server after a failover or move, verify that the router/switch between the client and the cluster is able to correctly handle the ARP cache flush protocol. For more information, see Related Topics.

Related Topics